Is this necessary given that you can just do ipfs daemon --init --init-config <template>?

Is this necessary given that you can just do ipfs daemon --init --init-config <template>?

Most people expect use containers as something fungible (or at least, be able to). Since you can't apply new config without restarting the daemon you must use volumes.

I think is very very useful be able start a fresh ipfs container with all desired config with just one cammand and ready to use

We think that #8337 is preferred, but we'll dialog about that there.

This PR was discussed again during GO triage on 2021-09-03, my quick summary:

• This will work only for a subset of config options
  • For example, there is a hidden complexity in regard to go-ipfs config file syntax around dynamic maps (DNS, pinning service credentials) which makes us worried about the need for domain-specific syntax here – see fix(config): support dynamic map keys with dots #8096. This is not a blocker, but acts as a strong signal this way of setting config will produce bugs and bad ux.
• Might create confusion
  • This PR adds env variables that work only with Docker, and not standalone go-ipfs.
  • Usually, passing env variables acts as an ad-hoc-one-time override, while this PR makes a permanent change to the config. Restarting container without variable does not restore previous value, which is another papercut which we would like to avoid.
  • If we ever add env variable based config override, it should be supported in go-ipfs natively (go-ipfs/docs/environment-variables.md), and work as "ad-hoc" override that does not mutate the config file.

In short, the decision was to not do this and close this PR without merging, and go with explicit docker hooks proposed in #8337

Thank you for the PoC and pushing the discussion forward @vk496 👍